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Abstract -This paper introduces the wide range of technical, legal, 
and political issues associated with the • interconnection of packet- 
switched data communication networks. Motivations for interconnec¬ 
tion are given, desired user services are described, and a range of tech¬ 
nical choices for achieving interconnection are compared. Issues such 
as the level of interconnection, the role of gateways, naming and 
addressing, flow and congestion control, accounting and access control, 
and basic internet services are discussed in detail. The CCITT X.25/ 
X.75 packet-network interface recommendations are evaluated in terms 
of their applicability to network interconnection. Alternatives such as 
datagram operation and general host gateways are compared with the 
virtual circuit methods. Some observations on the regulatory aspects of 
interconnection are offered and the paper concludes with a statement 
of open research problems and some tentative conclusions. 

I. Introduction 

I T IS THE THEME of many papers in this issue, that people 
need access to data resources. In many cases this access 
must be over large distances, in others it may be local to a 
building or a single site. Data networks have been set up to 
meet many user needs—often, but not necessarily, using packet- 
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switching technology. For single organizations, these A»» 
networks are often private ones, built with a lechnofcc 
optimized to the specific application. For 0010100 ™.:!!'-’* 
between organizations, these networks are being set u; * 
licensed carriers. In North America, there are many 
licensed carriers, e.g., TELENET [I], DATAPAC 1-1. *** 
TYMNET [3], In the rest of the world, the Post, Teleps 4 
and Telephone Authority (PTT) in each country has 1 
monopoly on such services; special public data nri**** 1 
being set up in these countries include TRANSPAC I — * 
France, EURONET [6] for inter-European traffic, DDX • 
in Japan, EDS [8] in the Federal Republic of Germany. *** 
the Nordic Public Data Network (NPDN, [9]) in Scanduu** 
These public data networks are considered in greater 
in other references (e.g., [ 10] —[ 12]). Most of the abort J*" 
works use packet-switching technology; some of them. **“ 
EDS and the NPDN, do not do so yet, but may do so >* 
future. In some cases special data networks have been 
rized for specific communities, e.g., SITA [13] for the 
and SWIFT [14] for the banks. In addition many print* 
works have been set up among individual organization^ ^ 
experimental networks of different technologies 
developed also, e.g., ARPANET [15], [16], CYCD^ 
[17], ETHERNET [18], SPYDER [19], PRNET [20]. f 
and SATNET [22]. 
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ij a common user requirement that a single terminal and 
^ port should be able to access any computing resource 
user may desire—even if the resource is on another data 

* or lc. From this requirement, there is a clear user need to 
*** data networks connected together. By the same token, 
providers of data network services would like to have their 
|^orks used as intensively as possible; thus they also have a 

, D g motivation to connect their data networks to others, 
a result of these considerations, there has been a high 
„ Dt interest in the issues arising in the connection of data 
^"vorks [ 23]-[26], [32]. 

r-om the user viewpoint, the requirement for interconnec- 
0 f data networks is independent of the network tech- 
” jy From the implementation viewpoint, there can be 
_, f considerable complications in connecting networks of 
r i,|v different technologies-such as circuit-switched and 

* jeram packet-switched networks (these terms are explained 

On the whole we will consider only, in this paper, the 
.--connection of packet-switched data networks. In many 
as. however, the arguments will be equally valid for the inter¬ 
section of packet-switched to circuit-switched networks, 
viwork interconnection raises a great many technical, legal, 
: : political questions and issues. The technical issues gen- 
-l.'v revolve around mechanisms for achieving interconnec- 
■jt jnd their performance. How can networks be intercon- 
r:::d so that packets can flow in a controllable way from one 
gt to another? Should all computer systems on all nets be 
. « to communicate with each other? How can this be 
^:ved? What kind of performance can be achieved with a 
r of itu:rconnected networks of widely varying internal 
r.m and operating characteristics? How are terminals to be 
r:.a access to resources in other networks? What protocols 
r :;quired to achieve this? Should the protocols of one net 
■ "assisted into those of another, or should common proto- 
■t be defined? What kinds of communication protocol 
--.lards are needed to support efficient and useful inter- 
--.rction? Who should take responsibility for setting 
sriards? 

lie legal and political issues are at least as complex as the 
siaical cues. Can private networks interconnect to each 
or must they do so through the mediation of a public 
r *ork? How is privacy to be protected? Should there be 
*‘jo 1 over the kinds of data which move from one net to 
*die/? Are there international agreements and conventions 
might be affected by international interconnection of 
*• .networks? What kinds of- charging and accounting 
^es should apply to multinetwork traffic? How can faults 
** trr °rs be diagnosed in a multinet environment? Who 
‘’-Id be responsible for correcting such faults? Who should 

* ::s Ponsible for maintaining the gateways which connect 
^ together? 

cannot possibly answer all of these questions in this 
^ but we deal with many of them in the sections below. 
Paper is divided into eleven sections. In the next sec- 
*e provide some definitions, and in Section III we ex- 
^ some of the motivations for network interconnection. 
Jcction IV we discuss the range of end-user service require- 
, 15 an d choices for providing multinetwork service. Section 
the concept of computer-communication protocol 
^8- Section VI reviews the basic interconnection choices 
( produces the concept of gateways between nets, proto- 
^nslation and the impact of common protocols; it elabo- 
on the function of gateways. Section VII discusses 


the CCITT recommendations X.25 and X.75 and their role in 
network interconnection. Section VIII describes some of the 
network interconnections achieved and some of the experi¬ 
ments in progress. Section IX outlines regulatory issues raised 
by network interconnection alternatives. Section X mentions 
some unresolved research questions, and the final section 
offers some tentative conclusions on network interconnection 


II. The Definition of Terms 

The vocabulary of networking is extensive and not always 
consistent. We introduce some generic terms below which we 
will use in this paper for purposes of discussion. It is impor¬ 
tant for the reader not to make any a priori assumptions about 
the physical realization of the objects named or of the bound¬ 
ary of jurisdictions owning or managing them. For instance, 
a gateway (see below) might be implemented to share the 
hardware of a packet switch and be owned by a packet-switch¬ 
ing service carrier; alternatively it might be embedded in a host 
computer which subscribes to service on two or more com¬ 
puter networks. Roughly speaking, we are assigning names to 
groups of functions which may or may not be realized as 
physically distinct entities. 

Packet: A packet of information is a finite sequence of bits, 
divided into a control header part and a data part. The header 
will contain enough information for the packet to be routed 
to its destination. There will usually be some checks on each 
such packet, so that any switch through which the packet 
passes may exercise error control. Packets are generally 
associated with internal packet-network operation and are not 
necessarily visible to host computers attached to the network. 

Datagram: A finite length packet of data together with 
destination host address information (and, usually, source 
address) which can be exchanged in its entirety between hosts, 
independent of all other datagrams sent through a packet 
switched network. Typically, the maximum length of a data¬ 
gram lies between 1000 and 8000 bits. 

Gateway: The collection of hardware and software required 
to effect the interconnection of two or more data networks, 
enabling the passage of user data from one to another. 

Host: The collection of hardware and software which uti¬ 
lizes the basic packet-switching service to support end-to-end 
interprocess communication and user services. 

Packet Switch: The collection of hardware and software re¬ 
sources which implements all intranetwork procedures such as 
routing, resource allocation, and error control and provides ac¬ 
cess to network packet-switching services through a host/ 
network interface. 

Protocol: A set of communication conventions, including 
formats and procedures which allow two or more end points 
to communicate. The end points may be packet switches, 
hosts, terminals, people, file systems, etc. 

Protocol Translator: A collection of software, and possibly 
hardware, required to convert the high level protocols used in 
one network to those used in another. 

Terminal: A collection of hardware and possibly software 
which may be as simple as a character-mode teletype or as 
complex as a full scale computer system. As terminals increase 
in capability, the distinction between “host” and “terminal” 
may become a matter of nomenclature without technical 
substance. 

Virtual Circuit: A logical channel between source and desti¬ 
nation packet switches in a packet-switched network. A 
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virtual circuit requires some form of “setup” which may or 
may not be visible to the subscriber. Packets sent on a virtual 
circuit are delivered in the order sent, but with varying delay. 

PTT: Technically PTT stands for Post, Telegraph, and Tele¬ 
phone Authority; this authority has a different form in differ¬ 
ent countries. In this paper, by PTT we mean merely the 
authority (or authorities) licensed in each country to offer 
public data transmission services. 

We have attempted to make these definitions as noncontro- 
versial as possible. For example, in the definition of packet 
switch, we alluded to a host/network interface. The reader 
should not assume that subscriber services are limited to those 
offered through the host/network interface. The packet¬ 
switching carrier might also offer host-based services and 
terminal access mechanisms as additional subscriber services. 

III. The Motivating Forces in the 
Interconnection of Data Networks 

In the introduction, we mentioned that there was a strong 
interest, among both the users and suppliers of data serivces, in 
the interconnection of data networks. However, the technical 
interests of the different parties are not identical. The end 
user would merely like to be able to access any resources from 
a single terminal, with a single access port, as economically 
as possible according to his own performance criteria. A 
Public Carrier, or PTT, has a strong motivation to connect its 
network to other PTT’s. As in the telephone system, the 
concept of all subscribers being accessible through a single 
Public Data Service, is considered highly desirable; however 
the different PTT’s may have restricted geographic coverage, 
or only a specific market penetration. 

The motivation of the PTT’s to interface to private networks 
is weaker and more complex. They always provide facilities 
to attach single terminals, where a terminal may be a complex 
computer system; they are often not interested, at present, in 
making any special arrangements when the “terminal” is a 
whole computer network. The operators of private networks 
often have a vital interest in connecting their networks to 
other private networks and to the public ones. Even though 
in many cases the bulk of its traffic is internal to the private 
network, which is why it was set up in the first place, there is 
usually a vital need to access resources not available on that 
network. The regulatory limitations often imposed on the 
method of interconnection of private networks are discussed 
in Section IX. In some countries, it is not permitted to build 
private networks using leased line services, but intrabuilding 
networks may be permitted. Interconnection of such local 
networks to public networks may play a crucial role in making 
the local network useful. 

To date the PTT’s have tried to standardize on access pro¬ 
cedures for their Public-Packet Data Services. The standardiza¬ 
tion has taken place in the International Consultative Commit¬ 
tee on Telegraphy and Telephony (called CCITT) in a set of 
recommendations called X.3, X.25, X.28, and X.29 ([27]- 
[29]). Not all PTT’s have such forms of access yet, but most 
of the industrialized nations in the West are moving in this 
direction. This series of recommendations is discussed in 
much more detail in Section VI; it does not pay special atten¬ 
tion to the attachment of private networks ([31], [32]), but 
the recommendations are themselves expected to change to 
meet this requirement. The PTT’s are agreeing on a set of inter¬ 
face recommendations and procedures called X.75 [33], to 
connect their networks to each other; so far this interface 
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procedure (and its corresponding hardware) is not • 
to be provided to private networks. 

While most PTT’s have preferred to ignore the t c w 
implications of the attachment of private networks f* 4 
public ones, most private network operators cannot ° ** 
this requirement. They are often motivated to add somt*^ 
“Foreign Exchange” capability as an afterthought, with . 
mum change to their intranetwork procedures; this app?^ 1 
can be successful up to a point, but will usually be limits ■ 
the lack of high-level procedures between the different ^ I 
works. These high-level procedures have not vet been 
sidered by CCITT, but it has been proposed that CCITT S-- f. 
Group VII investigate high-level procedures and architc<v 
models, in cooperation with the investigation of "open j 
architectures” by Technical Committee 97, Sub-Comnu:t» ' 
16 of the International Standards Organisation (ISO) n„ 
subject is also considered later in this paper, in Section VI 
. An aim of these standardization exercises is to ensure x, 
both manufacturer and user implementations of nct»« 
resources can communicate with each other through u;<» 
private or public data networks. A consequence shouri » 
that the resources are also compatibly accessible over 
nected data networks. 

Depending on the applications and spatial distribution .r 
subscribers, the preferred choice of packet-switching inti... 
will vary. Intrabuilding applications such as electronic 
services may be most economically provided through the 
of a coaxial-packet cable system such as the Xerox ETI11R v •' 
[18] and LCSNET [64], or twisted pair rings such u 5*'• 
[34], coupled with a mix of self-contained user compvt*™ 
(e.g., intelligent terminals with substantial computint »*u 
memory capacity) and shared computing, storage, and 1 =^ 
output facilities. Larger area regional applications might 
employ shared video cables [35] or packet radios [20] .11 
for mobile use. National systems might be composed o(r«» 
ture of domestic satellite channels and conventional leu** 
line services. International systems might use point-top^” 
links plus a shared communication satellite channel and tem¬ 
ple ground stations to achieve the most cost-effective scr>v> 

A consequence of the wide range of technologies wtu-- 
optimum for different packet-switching applications u 
many different networks, both private and public viayci?*'^ 
A network interconnection strategy, if properly designe-. - 
permit local networks to be optimized without sacrifice 
possibility of providing effective internetwork services 
potential economic and functional advantages of ‘O-'i- 
works such as ETHERNET or DCS will lead naturally >• : 
vate user networks. Such private network development ^ 
analogous to telephone network private automated 
exchanges (PABX) and represent a natural consequc*^ 
the marriage of computer and telecommunication techn - 

Two further developments can be expected. First. 
tions which are dispersed geographically, nationally, 01 ^ 
nationally, will want to interconnect these private ncl ^^ 
both to share centralized resources and to effect t ntraor \L^, 


tion electronic mail and other automated office 




Second, there will be an increasing interest in interorgarr^^ 
interconnections to allow automated procurement and 
transaction services, for example, to be applied to inte 
zation affairs. 

In most countries where private networks are P 
interorganization telecommunication requires the m 
of a PTT. Hence the most typical network interc° n 
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^05 will involve three or four networks. Within one na- 
administration the private nets of different organiza- 
*** will be interconnected through a public network. Inter- 
^ na j interconnections will involve at least two public 
Dorics. We will return to this topic in Section VI. 

*la addition to permitting locally optimized networks to be 
■connected, a network interconnection strategy should 
5 \ support the gradual introduction of new networking 
Oology into existing systems without requiring simul- 
-ious global change throughout. This consideration leads 
. t f, e conclusion that the public data networks should sup- 
.-t the most important user requirements for internet service 
..-a the outset. If this were the case, then changes in net- 
j technology which require a multinetwork system during 
■iised transition would not, a priori, have to affect user 
1 eoices. 

V. Provision of End-User Multinetwork Services 

pjie ultimate choice of a network interconnection strategy 
j be strongly affected by the types of user services which 
-jt be supported. It is useful to consider the range of exist- 
^ and foreseeable user service requirements without regard 
• ;he precise means by which these requirements are to be 
We will leave for discussion in subsequent sections the 
zxce of supporting the various services within or external to 
.. packet-switched network. The types of service discussed 
• slow are general requirements for network facilities. For this 
-non they also should be supported across interconnected 
j =:works. 

Most of the currently prevalent computer-communication 
| oices fall into four categories: 

!I terminal access to time-shared host computers; 
j remote job entry services (RJE); 

•I bulk data transfer; 

! ) transaction processing. 

The time-sharing and transaction services typically demand 
tort network and host response times but modest bandwidth, 
lie RJE and file transfer services more often require high 
mounts of data transfer, but can tolerate longer delay. Some 
xtworks were designed to support primarily terminal service, 
erring RJE or File transfer services to be supported by dedi- 
ated leased lines. Packet-switching techniques permit both 
Tpes of service to be supported with common network 
■sources, leading to verifiable economies. However, bulk 
| ina transfer requires increasingly higher throughput rates if 
fclivery delays are to be kept constant as the amount of 
hta to be transferred increases. 

's distributed operating systems become more prevalent, 
i: <e will be an increased need for host-to-host transaction 
"•"rices. A prototypical example of such a system is found in 
i: DARPA National Software Works [4], [36]. In such a 
small quantities of control information must be ex- 
^aged quickly to coordinate the activity of the distributed 
-wiponents. Broadcast or multidestination services will be 
^ded to support distributed file systems in which informa- 
■ on can be stored redundantly to improve the reliability of 
"cess and to protect against catastrophic failures. 

Transaction services are also finding application in reserva- 
| systems, credit verification, point of sale, and electronic 
•nds-transfer systems in which hundreds or thousands of 
| 'finals supply to, or request of, hosts small amounts of 
-“illation at random intervals. Real-time data collection for 
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Fig. 1. Network concatenation. 


weather analysis, ground and air traffic control, and meter 
reading, for example, also fall into this category. 

More elaborate user requirements can be foreseen as elec¬ 
tronic mail facilities propagate. Multiple destination address¬ 
ing and end-to-end encryption for the protection of privacy 
as well as support for text, digitized voice, and facsimile mes¬ 
sage transmission are all likely requirements. Electronic tele¬ 
conferencing using mixtures of compressed digital packet 
speech, videographics, real-time cursors (for pointing at video 
images under discussion), and text display will give rise to re¬ 
quirements for closed user groups and time-synchronized 
mixes of transaction-like (e.g., for cursor tracking and packet 
speech) and reliable circuit-like services (e.g., for display 
management). 

Reliability and rapid response will be increasingly important 
as more and more computer-based applications requiring tele¬ 
communications are integrated into the business, government, 
military, and social fabric of the world economy. The more 
such systems are incorporated into their daily activities, the 
more vulnerable the subscribers are to failures. Reliability 
concerns lead to the requirement for redundant alternatives 
such as distributed file systems, richly connected networks, 
and substantial local processing and storage capability. These 
trends increase the need for networking to share common 
hardware and software resources (and thus reduce their mar¬ 
ginal cost), to support remote software maintenance and de¬ 
bugging, and to support intra- and inter-organizational infor¬ 
mation exchange. 

We have described the end-user services required across one 
or more data networks. We have carefully refrained from dis¬ 
cussing which services should be provided in the data network, 
and- which should be provided in the hosts. Here the choice 
in single networks will depend on the network technology and 
the application requirements. For example, in a network using 
a broadcast technology such as ETHERNET or the SATNET, 
multidestination facilities may well be incorporated in the data 
network itself. In typical store-and-forward networks, this 
feature might be provided at the host level by the transmission 
of multiple copies of packets. This example highlights im¬ 
mediately the difficulty of using sophisticated services at the 
data network level across concatenated networks. If A, B, 
and C are data networks connected as in Fig. 1, and A and C 
but not B support broadcast or real-time features, it is very 
difficult to provide them across the concatenation of A, £„ and 
C. 

The problem of achieving a useful set of internetwork ser¬ 
vices might be approached in several ways, as follows. 

1) Require all networks to implement the entire range of 
desired services (e.g., datagram, virtual circuit, broadcast, real- 
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time, etc.), and then attempt to support these services across 
the gateways between the networks. 

2) Require all networks to implement only the most basic 
services (e.g., datagram or virtual circuit), support these ser¬ 
vices across gateways, and rely on the subscriber to imple¬ 
ment all other services end-to-end. 

3) Allow the subscriber to identify the services which he 
desires and provide error indications if the networks involved, 
or the gateways between them, cannot provide the desired 
services. 

4) Allow the subscriber to specify the internetwork route to 
be followed and depend on the subscriber to decide which 
concatenation of services are appropriate and what end-to-end 
protocols are needed to achieve the ultimately preferred class 
of service. 

■ 5) Provide one set of sendees for local, use within each net¬ 
work and another, possibly different set for internetwork 
use. 

The five choices above are by no means exhaustive, and, in 
fact, only scratch the surface of possibilities. Nothing has 
been said, thus far, about the compatibility of various levels 
of communication protocols which exist within each network, 
within subscriber equipments, and within the logical gateway 
between networks. To explore these issues further, it will be 
helpful to have a model of internetwork architecture, taking 
into account the common principle of protocol layering and 
the various possible choices of interconnection strategy which 
depend upon the protocol layer at which the networks are 
interfaced. We consider this in the next section. 

V. Layered Protocol Concepts 
Both to provide services in single networks, and to compare 
the capabilities of different networks, a very useful concept 
m networking is protocol layering. Various services of increas¬ 
ing capability can be built one on top of the other, each using 
the facilities of the service layer below and supporting the 
facilities of the layer above. A thorough tutorial on this con¬ 
cept can be found in the paper by Pouzin and Zimmermann in 
this issue [37]. We give some specific examples below of layer¬ 
ing as a means of illustrating the scope of services and inter¬ 
faces to be found in packet networks today-and some of the 
problems encountered in offering services across multiple 
networks. 

Table I offers a very generic view of a typical protocol 
hierarchy in a store-and-forward computer network, including 
layers usually found outside of the communication network 
itself. There are several complications to the use of generic 
protocol layering to study network interconnection issues. 
Chief among these is that networks do not all contain the same 
elements of the generic hierarchy. A second complication is 
that some networks implement service functions at different 
protocol layers. For instance, virtual circuit networks imple¬ 
ment an end/end subscriber virtual circuit in their intranet, 
end/end level protocol. Finally, the hierarchical ordering of 
functions is not always the same in all networks. For instance, 
TYMNET places a terminal handling protocol within the net¬ 
work access layer, so that hosts look to each other like-one or 
more terminals. Figs. 2-7 illustrate the functional layering 
of some different networks. It is important to note how the 
functions vary with the choice of transmission medium. 

A. ETHERNET 

In Fig. 2, we represent the Xerox ETHERNET protocol 
hierarchy. The basic link control mechanism is the ability of 
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Fig. 2. ETHERNET protocol layering. 


the interface device to detect conflict on a shared coaxial 
If a transmitting interface detects that another interri.' ■ 
also transmitting, it immediately aborts the transmi»w* 
Hosts attached to the network interface present dalagrunei 
be transmitted and are told if the datagram ivas abort** 
Datagrams can be addressed to specific interfaces or to iS ;l 
them. The end/end subscriber layer of protocol is split s-' 
two parts: a reliable datagram protocol in which each 4* 1 * 
gram is reliably delivered and separately acknowledged. *** 
a stream protocol which can be thought of as a virtual cir.'s* 
This split is possible, in part, because there is a fairly 
maximum datagram size (about 500 bytes) so that user *77* 
cations can send datagrams without having to fragment »** 
reassemble them. This makes the datagram service useful — 
many applications which might otherwise have to use 3* 
stream protocol. All higher level protocols, such as \ *••*** 
Terminal and File Transfer, are carried out in the hosts. 


B. ARPANET 

The ARPANET protocol hierarchy is shown in Fig. 
basic link control between packet switches treats the ph> 
link as eight independent virtual links. This increases ‘ • ^ 
tive throughput, but does not necessarily preserve the 
in which packets were originally introduced into the 
The intranet node-to-node protocols deal with adapti' e 
ing decisions, store-and-forward service, and congest! 0 ® , 
trol. Hosts have the option of either passing messages J 
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,yi3 bits of text) across the host/network interface, which 
,,]l be delivered in sequence to the destination, or passing 
diagrams (up to 1008 bits of text) which are not necessarily 
slivered in sequence. The user's network access interface is 
yiagram-like in the sense that no circuit setup exchange is 
:reded even to activate the sequenced message service. In 
•::'tct, this service acts like a permanent virtual circuit over 

■ tich a sequence of discrete messages are sent. For the 
fenced messages, there is exactly one virtual circuit main¬ 
lined for each host/host pair. In fact, these virtual circuits 
L -r set up dynamically and terminated by the source/destina- 
x>n packet switches so as to improve resource utilization 

;s], [ 62 ], 

The end/end subscriber layer of ARPANET contains two 
eiin protocols: Network Control Protocol (NCP, [39], [40]) 
ud Transmission Control Protocol (TCP, [25]). NCP was the 
trst interprocess communication protocol built for ARPANET. 

: relies on the sequenced message service provided by the net- 
ork and derives multiple virtual circuits between pairs of 
::sts by multiplexing. The TCP can use either the sequenced 
rrssage service or the datagram service. It does its own 
quencing and end/end error control and derives multiple 
r -'tual circuits through extended addressing and multiplexing. 

■ CP was designed for operation in a multinet environment in 
•hich the , only service which reasonably could be expected 
•nan unreliable, unsequenced datagram service. 

To support experiments in packetized voice communication, 
'•o protocols were developed for use on the ARPANET. The 
'ttwork Voice Protocol (NVP) and Network Voice Confer¬ 
ring Protocol (NVCP) use the datagram service to achieve 
"ry low delay and interarrival time-variance in support of 
•Stal, compressed packet speech (more on these protocols 
; *y be found in [41]). The NVP could be considered the 
for a generic protocol which could support a variety of 
'-d-tinis, end/end user applications. 

higher level utility protocols such as terminal/host 
■'otocol (TELNET, [40], [42]) and file transfer protocol 
[40], [42]) use virtual circuits provided by NCP or TCP. 
• 3t FTP requires one live interactive stream to control the 
JtJ transfer, and a second for the data stream itself. Yet 
^ er level applications such as electronic mail and remote 
*«*y (RJE, [40], [42]) use mixtures of TELNET and 
' ” to effect the service desired. These protocols are usually 
mto the hosts. There is one anomaly, which occurs in 
^ networks. Because terminal handling is required so 
"-lUently, a Terminal Interface Message Processor (TIP, [43 ]) 
** kuilt. This device is physically integrated with the packet 
(IMP, [38]); it includes also the NCP and TELNET 
* ot ocols. 


TYMNET (see Fig. 4) is one of the oldest of the networks in 
the collection described here [3]. Strictly speaking, it oper¬ 
ates rather differently than other packet-switched networks, 
because the frames of data that move from switch to switch 
are disassembled and reassembled in each switch as an integral 
part of the store-and-forward operation. Nevertheless, the net¬ 
work benefits from the asynchronous sharing of the circuits 
between the switches in much the same way that more typical 
packet-switched networks do. The network was designed to 
support remote terminal access to time-shared computer re¬ 
sources. The basic service is the transmission of a stream of 
characters between the terminal and the serving host. A 
frame is made up of one or more blocks of characters, each 
block labeled with its source terminal identifier and length. 
The switch-to-switch layer of protocol disassembles each frame 
into its constituent blocks and uses a routing table to deter¬ 
mine to which next switch the block should be sent. Blocks 
destined for the same next switch are batched together in a 
frame which is checksummed and sent via the link control 
procedure to the next switch. Batching the blocks reduces 
line overhead (the blocks share the frame checksum) at the 
expense of more CPU cycles in the switch for frame dis¬ 
assembly and reassembly. 

The protocol between TYMNET switches also includes a 
flow control mechanism which, because of the fixed routes, 
can be used to apply back pressure all the way back to the 
traffic source. This is not precisely an end-to-end flow control 
mechanism, but a hop-by-hop back pressure strategy. Charac¬ 
ter blocks are kept in sequence along the fixed routes so that 
no resequencing is required as they exit from the network at 
their destinations. The network interface is basically a virtual 
circuit designed to transport character streams between a 
host and a terminal. The same virtual circuits can be used to 
transport character streams between hosts, which look to each 
other like a collection of terminals. Above the basic virtual 
circuit service, is a special echo-handling protocol which 
allows the host and the terminal handler in the “remote 
TYMSAT” to coordinate the echoing of the characters typed 
by a user. 

D. PTT Networks 

Many PTT networks, e.g., TELNET, TRANSPAC, DATA- 
PAC, and EURONET use a particular network-access protocol, 
X.25 [28], [29] (see Fig. 5). This protocol has been recom¬ 
mended by the CCITT for public packet-switched data .net¬ 
works. X.25 is a three-part protocol consisting of a hardware 
electrical interface, X.21 [44], the digital equivalent of the 
usual V.24 or EIA-RS232C modem interface [45], a link 
control procedure, High Level Data Link Control (HDLC, 
[46]), and a packet-level protocol for effecting the setup, 
use, termination, flow, and error control of virtual circuits. 
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Ln all but the DATAPAC network, a fixed route for routing 
packets through the network is selected at the time the virtual 
circuit is created. “Permanent” virtual circuits are a customer 
option; if used, the setup-phase is invoked only in the case of 
a network failure. Between source and destination packet 
switches, a virtual circuit protocol is operated which imple¬ 
ments end-to-end flow control on multiple virtual circuits 
between pairs of packet switches. Up to 4096 virtual circuits 
between pairs of host ports can be maintained by each packet 
switch, as compared to the single virtual circuit provided by 
ARPANET (on which hosts can multiplex their own virtual 
circuits). This choice has a noticeable impact on the sub¬ 
scriber interface protocol which becomes complicated be¬ 
cause the subscriber host and the packet switch to which it 
attaches must maintain a consistent view of the state of each 
virtual circuit in use. 

To provide for echo control, user commands, code conver¬ 
sion, and other terminal-related services, these networks 
implement CCITT Recommendations X.28 [29] and X.29 
[29] in a PAD (Packet Assembly and Disassembly unit). 
These protocols sit atop the virtual circuit X.25 protocol. In 
order to serve customers desiring a terminal-to-host service 
with character terminals, such as is provided by TYMNET or 
by the ARPANET (through the TIP), most of the PTT net¬ 
works mentioned are developing a PAD unit. A matching 
X.29 (PAD control protocol) layer must be provided in hosts 
offering to service terminals connected to PAD’S. 

E. High Level Protocols 

The X.25/X.28/X.29 protocol hierarchy does not include an 
end/end subscriber or high-level protocol layer. Some cus¬ 
tomers will, in fact, implement end-to-end protocols on top 
of the virtual circuit protocol, but others may not. Several 
attempts are being made to standardize protocols above the 
network access level. The ARPANET community has de¬ 
veloped a Transmission Control Protocol [25] for internet¬ 
work operation to replace the Network Control Program 
(NCP) developed early in the ARPANET project. The Inter¬ 
national Federation of Information Processing (IFIP) has 
proposed a Transport Station through its Working Group 6.1 
on Network Interconnection [47]; the proposal has been sub¬ 
mitted to the International Standards Organisation (ISO) as 
a draft standard. In addition, other communities, e.g., the 
High Level Protocol Working Group in the UK, have devised 
protocols for Virtual Packet Terminals (VPT, [48]) and File 
Transport Protocol (FTP, [49]) which are intended to be net¬ 
work independent and which may be submitted to CCITT. 
The ISO study on “open systems architecture” and the pro¬ 
posed similar study by CCITT Study Group VII will attempt 
to evolve higher level protocol recommendations for existing 
and future data networks. 



This brief summary of different network-protocol ] a y e 
is in no way comprehensive, but illustrates the diversity^ 0 
protocol designs which can be found on nets providing dj/< ‘ 
ent types of services to subscribers. 

VI. Technical Interconnection Choices 

A. The Issues 

Beginning with the earliest papers dealing with stratcj*, 
for packet-network interconnection [23]-[26], [ 32 j ,, 
common objective of all the proposed methods is to proi-i, 
the physical means to access the services of a host on one nr; 
work to all subscribers (including hosts) of all the intercca. 
nected networks. Of course, limitations to this accessibi:, 
are envisaged, imposed either for administrative reasoni - s 
by the scarcity of resources. The achievement of this ob-« 

' tive invariably requires that data produced at a source in qz, 
net be delivered and correctly interpreted at the destination i 
in another network. In an abstract sense, this boils dour.: : 
providing interprocess communication across network bour: 
aries. Even if a person is the ultimate source of the dm 
packet-switching networks must interpose some degree of xf 
ware processing between the person and the destination ur 
vice, even if only to assemble or disassemble packets produ.c! 
by a computer terminal. 

A fundamental aspect of interprocess communication : 
that no communication can take place without some apt*: 
conventions. The communicating processes must share w-m 
physical transmission medium (wire, shared memory, 
spectrum, etc.), and they must use common convention ■ 
agreed upon translation methods in order to successful!; ti 
change and interpret the data they wish to communicate. (V -» 
of the key elements in any network interconnection striuc 
is therefore how the required commonality is to be obtai.-.N 
In some cases, it is enough to translate one protocol -- 
another. In others, protocols can be held in common 
the communicating parties. 

In any real network interconnection, of course, a numtv: > 
secondary objectives will affect the choice of interconnect. * 
strategy. For example achievable bandwidth, rcliari- 
robustness (i.e., resistance to failures), security, fleNiht- ‘ 
accountability, access control, resource allocation options, ti¬ 
the like can separately and jointly influence the choice 
interconnection strategy. Combinations of strategies emri-"' 
ing protocol standards and protocol translations at ' 3 -- 
levels of the layered protocol hierarchy are also Im¬ 
possibilities. 

There are a number of issues which must be resolved h<--, 
a coherent network interconnection strategy can be dcL- 
A list of some of these issues, which will be treated m ~ 
detail in succeeding sections, is: 

1) level of interconnection; 

2) naming, addressing, and routing; 

3) flow and congestion control; 

4) accounting; 

5) access control; 

6) internet services. 

B. Gateways and Levels of Network Interconnection 

The concept of a gateway is common to all network ( 
connection strategies. The fundamental role of th e 
to terminate the internal protocols of each network 0 
it is attached while, at the same time, providing 3 
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pound across which data from one network can pass into 
mother. However, the choice of functions to be performed in 
’je gateway varies considerably among different interconnec- 
ton strategies (see Fig. 6). The term “gateway” need not 
-■aply a monolithic device which joins a pair-of networks. In- 
' Iced, the gateway may merely be software in a pair of packet 
"itches in different networks, or it may be made up of two 
Puts, one in each network (a sort of “gateway half”). In the 
-nter case, the two halves might be devices separate and 
•ntinct from the network packet switches or might be inte¬ 
nd with them. Furthermore, a gateway might interconnect 
3 °re than two networks. In the material which follows, 
r,c ry attempt has been made to avoid any implicit choice of 
Uteway implementation. It is worth pointing out, however, 
■'■'at the “half gateway” concept is highly attractive from both 
1 le chnical and a purely administrative point of view. Tech- 
^cally, each half could terminate certain levels of protocol 
51 the net to which it is attached. Administratively each half 
•Nd be the responsibility of the network to which it belongs. 
“ en the only matters for jurisdictional negotiation are the 
Physical medium by which the half-gateways exchange data, 
the format and protocol of the exchange. 


It is important to realize that typical applications may in¬ 
volve three or more networks. Where local networks are used, 
they will usually need to be interconnected to realize the 
benefits of interorganizational data exchange. In most coun¬ 
tries, such interconnections will only be permitted through a 
public network. Thus for a typical national situation, three 
networks and two gateways will be involved in providing the 
desired host-to-host communication. 

The international picture is similar, except that more net¬ 
works are likely to be involved. Shown in Fig. 7, the path 
from a host, S, on local network LN(A) in country A, passes 
through a public network, PN(A) in country A , through an in¬ 
ternational network IN, through a public network PN(B) in 
country B, and finally through a local network, LN(B ), to the 
destination host, D. There are four internetwork gateways 
involved. It is this model involving multiple gateways that 
guides us away from network interconnection methods which 
rely on the source and destination hosts being in adjacent 
networks connected by the mediation of a single gateway. 

lj Common Subnet Technology (Packet Level Intercon¬ 
nection): The level at which networks are interconnected can 
be determined by the protocol layers terminated by the gate¬ 
way. For example, if a pair of identical networks were to be 
interconnected at the interpacket-switch level of protocol, 
we might illustrate the gateway placement as shown in Fig. 8. 
Here the “gateway” may consist only of software routines in 
the adjacent packet switches, e.g., P(A) and P(_B), which pro¬ 
vide accounting, and possibly readdressing functions. The 
contour model of protocol layer is useful here since it shows 
which levels are common to the two networks and which 
levels could be different. In essence, those layers which are 
terminated by the gateways could be different in each net, 
while those which are passed transparently through the gate¬ 
way are assumed to be common in both networks. This net¬ 
work interconnection strategy requires that the internal ad¬ 
dress structure of all the interconnected networks be common. 
If, for example, addresses were composed of a network identi¬ 
fier, concatenated with a packet-switch identifier and a host 
identifier, then addressing of objects in each of the networks 
would be straightforward and routing could be performed on 
a regional basis with the network identifiers acting as the 
regional identifiers, if desired. Alternatively, two identical 
networks could adopt a common network name and assign 
nonduplicative addresses to each of the packet switches in 
both networks. This may require that addresses in one net¬ 
work be changed. 

The strategy described above might be called the “common 
subnetwork strategy,” since, in the end, subscribers of the 
newly formed joint network would essentially see a single 
network. This strategy does not rule out the provision of 
special access control mechanisms in the gateway nodes which 
could filter traffic flowing from one network into the other. 
Similarly, the gateway nodes could perform special internet¬ 
work traffic accounting which might not normally be per¬ 
formed in a subnet switching node. This network interconnec¬ 
tion method is limited to those cases in which the nets to be 
connected are virtually identical, since the gateways must 
participate directly in all the subnet protocols. The end-to- 
end subnet protocols (e.g. source/destination packet-switch 
protocols) must pass transparently through the gateways to 
permit interactions between a source packet switch in one 
net and a destination packet switch in another. The resulting 
• network presents the same network access interface to all 
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subscribers, and this leads us to the next example which is 
based on the concept of a common network access interface. 

2) Common Network Access Interfaces: If the subnetwork 
protocols are not identical, the next opportunity to establish 
internetwork commonality is at the network access interface. 
This is illustrated in Fig. 9. Each network is assumed to have 
its own intranet protocols. However, each network presents 
the same external interface to subscribers. This is illustrated 
by showing a common interface passing through all hosts, 
marked “common network access interface” in the figure. 

Once again, the gateway could be thought of as software in 
adjacent packet switches. Each gateway is composed of two 
halves formed by linking the packet switches of two nets 
together. However, in this case, the subnetwork protocols are 
terminated at the gateway so that the intergateway exchange 
looks more like network access interaction than a node-to- 
node exchange. This is the approach taken by CCITT with 
its X.25 packet network interface recommendation and X.75 
intergateway exchange recommendation. 

It is important to note that the intergateway interface could 
be similar to the standard network access interface, but it 
need not necessarily be identical. 

There are two basic types of network interface currently in 
use: 1) the datagram interface [31]; and 2) the virtual circuit 
interface [32]. The details of these generic interface types 
vary in different networks; some networks even offer both 
types of interface. In some, the interface to use may be 
chosen at subscription time; in others it may be possible for a 
subscriber to select the access method dynamically. 


A datagram interface allows the subscriber to enter pacl«u 
into the network independent of any other packets whKi 
have been or will be entered. Each packet is handled separated 
by the network. A virtual circuit interface requires an <' 
change of control information between the subscriber and ti* 
network for the purpose, for example, of setting up addrru 
translation tables, setting up routes or preallocating resour.'** 
before any data packets are carried to the destination. Sos* 
networks may implement a fast select virtual circuit inter!** 
in which a circuit setup request is sent together with the (in¬ 
land possibly last) data packet. Other control exchanj** 
would be used to close the resulting virtual circuits set up 3 
this fashion. 

It is essential to distinguish datagram and virtual an.— 
services from datagram and virtual circuit interfaces. A dit* 
gram service is one in which each packet is accepted 
treated by the network independently of all others, 
quenced delivery is not guaranteed. Indeed, it may n0 j^ 
guaranteed that all datagrams will be delivered. * ,acke ^ >u( 4 
be routed independently over alternate network paths, 
cate copies of datagrams might be delivered. ^ 

Virtual circuit service tries to guarantee the sequenc 
livery of the packets associated with the same virtual cu* ^ 
It typically provides to the host advice from the ^ 

flow control per virtual circuit as opposed to the P ac ^^ T 
packet acceptance or rejection typical of a datagram 
If the network operation might produce duplicate P 
these are filtered by the destination packet switch j 
delivery to the subscriber. Duplicate packet crea 11 
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Fig. 9. Interconnection of networks with common network-access interfaces. 
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:ommon phenomenon as in packet-switched store-and-forward 
r.siems. The basic mode of operation is to forward a packet 
u the next switch and await an acknowledgment. After a 
meout, the packet is retransmitted. If an acknowledgment is 
jit due to line noise, for example, then two copies of the 
ticket would have been transmitted. Even if the next switch 
a prepared to filter duplicates out, a network which uses adap¬ 
ts routing can deliver a duplicate packet to the periphery of 
tie network. For example, if a packet switch receives a packet 
successfully but the line to the sender breaks before the re¬ 
viver can acknowledge, the sender may send another copy to 
1 Afferent packet switch. Both packet copies may be routed 
ud delivered to the destination packet switch where final 
Implicate filtering would be needed if virtual circuit service is 
^ing provided. 

Some networks offer both a datagram and a virtual circuit 
^ice; some offer a single interface, but different services, 
•or example, the ARPANET has a basic datagram interface. 
However, the subnetwork will automatically provide a se- 
Wnced virtual circuit service (i.e., packets are kept in 
t( luer.ce when they are delivered to the destination) if the 
hcket is marked appropriately. Otherwise, packets are not 
■olivered in sequence nor are packet duplicates or losses, 
ncc pt for line by link correction, recovered within the net- 
'ork for nonsequenced types of traffic. 

contrast, TRANSPAC offers a virtual circuit interface 
^ service. Subscribers transmit “call request” packets 
■ootaining the full destination address to the packet switch. 
. request packet is forwarded to the destination, leaving 
^iind a fixed route. The destination subscriber returns a 
^ accepted” packet which is delivered to the caller. As a 


result of this exchange, the source subscriber has associated a 
“logical channel number” or LCN, with the full source- 
destination addresses. Thus subsequent packets to be sent on 
the same logical channel are identified by the LCN and are 
kept in sequence when delivered to the destination. 

Finally, it is possible to implement a datagram-like service 
using a virtual circuit interface. In this case, the exchange of 
request and accept packets might be terminated at the sub¬ 
scriber’s local packet switch, so that even if packets were not 
delivered in sequence they might employ abbreviated address¬ 
ing for local subscriber and packet-switch interaction. 

If network interaction is to be based on a standard interface, 
then agreement must be reached both on the interface and an 
associated service or services. Furthermore, a common ad¬ 
dressing system is needed so that a subscriber on one network 
can address a packet to a subscriber on any other network. A 
weaker assumption could be made but we are deliberately 
assuming a truly common service, interface, and addressing 
mechanism. We will return to this topic in a later section. 

The choice of a standard network service through which to 
effect network interconnection has a primary impact on the 
flexibility of implementable network interconnection methods. 
We will consider two choices: datagram service and virtual 
circuit service. 

a) Datagram service as a standard for network intercon¬ 
nection: For this case, it is assumed that every network offers 
a common datagram service. A uniform address space makes it 
possible for subscribers on any network to send packets ad¬ 
dressed to aliy other subscriber on a connected network. Pac¬ 
kets are routed between subscriber and gateway and between 
gateways based on the destination address. No attempt is 
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made to keep the datagrams in any order in transit or upon de¬ 
livery to the destination. Individual datagrams may be freely 
routed through different gateways to recover from failures or 
to allow load-splitting among parallel gateways joining a pair 
of networks. 

The gateway/gateway interface may be different than the 
network access interface, if need be (see Fig. 9). 

This strategy requires that all networks implement a com¬ 
mon interface for subscribers. The simplicity and flexibility 
of the datagram interface strategy is offset somewhat by the 
need for all networks to implement the same interface. This is 
true for the pure virtual circuit interface strategy as well, as 
will be shown below. 

One of the problems which has to be faced with any net¬ 
work interconnection strategy is congestion control at the 
gateways. - Jf a gateway finds that it is unable to forward a 
datagram into the next network, it must have a way of reject¬ 
ing it and quenching the flow of traffic entering the gateway 
en route into the next network. The quenching would typi¬ 
cally take the form of an error or flow control signal passing 
from one gateway half to another on behalf of the associated 
network. Similar signals could be passed between subscribers 
and the packet network for similar reasons. Since datagram 
service does not undertake to guarantee end/end reliability, 
it is possible to relieve momentary congestion by discarding 
datagrams, as a last resort. 

b) Virtual circuits for network interconnection: Another 
alternative standard network service which could be used for 
network interconnection is virtual circuit service (Fig. 10). 
Independent of the precise interface used to “set up” the 
virtual circuit, a number of implementation issues immedi¬ 
ately arise if such a service is used as a basis for network 
interconnection. 

Since it is intended that all packets on a virtual circuit be 
delivered to the destination subscriber in the same sequence 
as they were entered by the source subscriber, it is necessary 
that either: 1) all packets belonging to the same virtual circuit 
take the same path from source subscriber, through one or 
more gateways, to destination subscriber; or 2) all packets 
contain sequence numbers which are preserved end-to-end 
between the source DCE in the originating network and the 
destination DCE in the terminating network. 

In the first case, virtual circuits are set up and anchored to 
specific gateways so that the sequencing of the virtual circuit 
service of each network can be used to preserve the packet 
sequence on delivery. This results in the concatenation of a 
series of virtual circuits through each gateway and, therefore, 
the knowledge of each virtual circuit at each gateway (since 
the next gateway to route the packet through must be fixed 
for each virtual circuit). 

In the second case, there is no need to restrict the choice of 
gateway routing for each virtual circuit since the destination 
DCE will have sufficient information to resequence incoming 
packets prior to delivery to the destination subscriber. 

In either case, the destination DCE will have to buffer and 
resequence packets arriving out of order due either to dis¬ 
ordering within the last network or to alternate routing among 
networks, if this is permitted. Some networks may keep 
packets in sequence as they transit the network. This will only 
be advantageous at the destination DCE if the packets enter 
the network in the desired sequence. If such a service is relied 
upon in the internet environment, then each gateway must 
assure that on entry to such a net, the packets are in the de- 
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Fig. 10. Virtual circuit network interconnection strategies, (r) s.i 
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how much of the X.25 VC service is terminated at the STE. (cl \ '■ 
based gateways with general virtual circuit networks. 


sired order for delivery to a destination subscriber or an.-:.‘-■ 
gateway. 

The buffering and resequencing of packets within the 
works or at gateways introduces substantial variation in hu.”- 
space requirements, packet transit delays, and the p'-;cntu.' i ■ 
buffer lockups to occur [50], [51 ], [61 ]. 

If packets for a specific virtual circuit are restricted lo r w 
through a fixed series of gateways, and if a standard ilo» 
control method is agreed upon as part of the virtual ci:.-‘ 
service, then it is possible for each internet gateway to pa:'.:- 
pate in end-to-end flow control by modifying the flow cor.:: > 
information carried in packets carried end-to-end from 
source DCE to the destination DCE. Consequently, a i‘' ! 
way may be able to adjust the amount of traffic pacuu 
through it and thereby achieve a kind of internet cate* 1 " 
congestion control. If this is done by allocating but for >r*-’ 
for “outstanding" packets, then either the gateways 
guarantee the advertised buffer space or there must be a ^ 
transmission capability built into the internet virtual 
implementation, perhaps between source DCE and destine—■' 
DCE or between DCE’s and gateways. . 

Such a mechanism does not, however, solve the problc- 
network congestion unless the gateway-flow control 
take into account resources both in the gateway and 
rest of the network. Although it is tempting to 3SSlime _^ r , 
virtual circuit-flow control can achieve internetwork c0 ^ ; 
tion control, this is by no means clear, and is still the su - 
of considerable research. . 

As a general rule, compared to the datagram met 0 _ ^ 
virtual circuit approach requires more state inform w 
each gateway, since knowledge of each virtual circuit 
maintained along with flow control and routing inform ^ 
The usual virtual circuit interface is somewhat more 
for subscribers to implement as well, because oi 
of state information which must be shared by the su 
and the local DCE. For example, implementations of 1 
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:::rface protocol have been privately reported by Computer 
ijrporation of America and University College London to 
rpjire 4000-8000 words of memory on Digital Equipment 
::poration PDP-11 computers. By contrast, the ARPANET 
ci Packet Radio Network datagram interfaces require 500- 
>X) words of memory on the same machine. For internet- 

• ::k operation, this may be even more burdensome, since 
cy failure at a gateway may require a subscriber-level re¬ 
entry through an end-to-end protocol, in addition to the 
•dual circuit interface software, as is shown in [ 52]. 

5:vertheless, it may be advantageous to consider internet¬ 
ting standards which usefully employ both datagram and 
rtual circuit interfaces and services. For example, some 
frrial internet services such as multidestination delivery may 

* more efficient if they are first set up by control exchanges 
'h’veen the subscriber an'd the local network and perhaps 
always as well. Once set up, however, a datagram mode of 
Oration may be far more efficient than maintaining virtual 
? niits for all destinations. Implicit virtual circuits which are 
''■ivated by simple datagram-like interfaces are also attrac¬ 
tor very simple kinds of terminal equipment. 

^ it is not possible for all networks to implement a common 
*t*ork-access interface, then the next opportunity is to 
^dardize only the objects which pass from one net to the 
* It and to minimize any requirements for the sequencing 
these objects as they move from net to net. 

General Host Gateways: In this model, a gateway is 
’‘■Anguish able from any other network host and will imple- 
' <,t whatever host/network interface is required by the 
^'orks to which it is attached. For many networks, this 
^ be X.25, but the strategy does not rely on this. The 
^jtt'Ple assumption is that packet networks are at least 
“' e of carrying subscriber packets up to some maximum 


length, which may vary from network to network. It is specif¬ 
ically not assumed that these packets will be delivered in order 
through intermediate networks and gateways to the destina¬ 
tion host. This minimal type of service is often termed “data¬ 
gram” service to distinguish it from sequenced virtual circuit 
service. A detailed discussion of the tradeoff between data¬ 
gram and virtual circuit types of networks is given elsewhere 
[52], 

The basic model of network interconnection for the data¬ 
gram host gateway is that internetwork datagrams will be 
carried to and from hosts and gateways and between gateways 
by encapsulation of the datagrams in local network packets. 
Pouzin describes this process generically as “wrapping” [37] . 
The basic internetwork service is therefore a datagram ser¬ 
vice rather than .a virtual .circuit, service.. -The concept is 
illustrated in Fig. 11. 

Datagram service does not offer the subscriber as many 
facilities as virtual circuit service. For example, not all data¬ 
grams are guaranteed to be delivered, nor do those that are 
delivered have to be delivered in the sequence they were sent. 
Virtual circuits, on the other hand, do attempt to deliver all 
packets entered by the source in sequence to the destination. 
These relaxations allow dynamic routing of datagrams among 
multiple, internetwork gateways without the need for sub¬ 
scriber intervention or alert. 

The internet datagram concept gives subscribers access to a 
basic internet datagram service while allowing them to build 
more elaborate end-to-end protocols on top of it. Fig. 12 
illustrates a possible protocol hierarchy which could be based 
on the internet datagram concept. The basic internet data¬ 
gram service could be used to support transaction protocols 
or real-time protocols (RTP) such as packet-voice protocols 
(PVP) which do not require guaranteed- or sequenced data 
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Fig. 12. Protocol layering with internetwork datagrams. 
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delivery; reliable, sequenced protocols could be constructed 
above the basic internet datagram service to perform end/end 
sequencing and error handling. Applications such as virtual 
terminal protocols (VTP) [40], [42], [48] or file-transfer 
protocols [40], [42], [49] could be built above a reliable, 
point-to-point, end/end service which is itself built atop inter¬ 
net datagrams. Under this strategy, the basic gateway func¬ 
tions are the encapsulation and decapsulation of datagrams, 
mapping of internet source/destination addresses into local 
network addresses and datagram routing. Gateways need not 
have any knowledge of higher level protocols if it is assumed 
that protocols above the internet datagram layer are held in 
common by the communicating hosts. Datagrams can be 
routed freely among gateways and can be delivered out of 
sequence to the destination host. 

The basic advantage of this strategy is that almost any sort 
of network can participate, whether its internal operation is 
datagram or virtual circuit oriented. Furthermore, the strategy 


offers an easy way for new networks to be made “back"-* '' 
compatible,” with older ones while allowing the new ono ■- 
employ new internal operations which are innovative or in¬ 
efficient. 

Every subscriber must implement the internet datagram 
cept for this strategy to work, of course. The same prob ** 
arises with the standard network interface strategy s IIKt 
subscribers must implement the same network interface. 

4) Protocol Translation Gateways: It would be mislea 
to claim that the concept of protocol translation hw ^ 
played a role in the discussion thus far. In a sense, the e 
sulation of internet datagrams in the packet format o ^ 
intermediate network is a form of protocol translation. 


T* 

t 


basic packet carrying service of one network is being 
lated into the next network’s packet carrying service 
13). This concept could be extended further. F° r ex3 (0 ^ 
if two networks have a virtual circuit concept, one o(11 p.T» 
mented within the subnetwork and the other through c 
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^t/host protocols, it might be possible, at the gateway be- 
• c en the nets ’ t0 ma P one network’s virtual circuit into the 
Cher’s- This same idea could be applied to higher level proto- 
' I mappt n 8 s 15 we *T. for instance, the virtual terminal proto- 
'^jl for one network might be transformed into that of another 
on the fly.” 

■p,e success of such a translation strategy depends in large 
on the commonality of concept between the protocols 
be translated. Mismatches in concept may require that the 
erv jce obtained in the concatenated case be a subset of the 
e( vices obtainable from either of the two services being trans- 
ie d. Extending such translations through several gateways 
jn be difficult, particularly if the protocols being translated 
not share a common address space for internetwork sources/ 
..jdnations. In the extreme, this strategy can result in sub- 
t nbers “logging in” to the gateway in order to activate the 
-etocols of the next network. Indeed, front-end computers 
,-ould be considered degenerate translation gateways since they 
.-nnsform host/front-end protocols into network protocols. 
There are circumstances when translation cannot be avoided. 
;or instance, when the protocols of one network cannot be 
-odified, but internet service is desired, there may be no 
L ;emative but to implement protocol translations. The model 
-.pically used to guide protocol translation gateways is that 
■j;s source/destination hosts lie on either side of the transla¬ 
te gateway. Concatenation of protocol translations through 
everal networks and gateways is conceivable, but may be very 
cfficult in practice and may produce very inefficient service. 


.'. ,V< lines. Addresses, and Routes 

In order to manage, control, and support communication 
i.nong computers on one or more networks, it is essential that 
inventions be established for identifying the communicators, 
ror purposes of this discussion, we will use the term host to 
tier to all computers which attach to a network at the net- 
ork-access level of protocol (see Table 1). Subscribers to 
ttminal-access services can be thought of as attaching to hosts, 
■■'tn if the host is embedded in the hardware and software of 
■ packet switch as a layer of protocol. Consequently, we can 
uy that the basic task of a packet-switching network is to 
-rnsport data from a source host to one or more destination 
costs. 

To accomplish this task, each network needs to know to 
‘hich destination packets are to be delivered. Even in broad¬ 
cast nets such as the ETHERNET, this information is neces 1 
ur y so that the' destination host "can discriminate packets 
hstined for itself from all others heard on the net. At the 
•f'vest-protocol levels it is typical to associate destinations 
*ith addresses. An address may be simply an integer or it 
-ay have more internal structure. 

M higher levels of protocol, however, it is more common to 
:n< * text strings such as “MULT1CS” or “BBN-TENEX" used 
11 names of destinations. Application software, such as elec- 
-otuc mail services, might employ such names along with 
aore refined destination identifiers. For example, one of the 
,J thors has an electronic mailbox named “KIRSTEIN at ISI” 
Stated in a computer at the University of Southern California's 
'formation Sciences Institute. 

Typically, application programs transform names into ad- 
-tsses which can be understood by the packet-switching net- 
<0t k. The networks must transform these addresses into 
JU,es to guide the packets to their destination. Some net- 
°*s bind addresses to routes in a relatively rigid way (e.g., 


setting up virtual circuits with fixed routing) while others 
determine routes as the packets move from switch to switch, 
choosing alternate routes to bypass failed or congested areas of 
the network. Broadcast networks need not create routes at all 
(e.g., SATNET). 

In simple terms, a name tells what an object is; an address 
tells where it is; and a route tells how to get there [54], A 
simple model involving these three concepts is that hosts trans¬ 
form names into addresses and networks transform addresses 
into routes (if necessary). However, this basic model does leave 
a large number of loose ends. The subject is so filled with 
issues that it is not possible in this paper to explore them all in 
depth. In what follows, some of the major issues are raised 
and some partial resolutions are offered. 

One major question is “Which objects in the network should 
have names? addresses?” Pouzin and Zimmermann offer a 
number of views on this question in their paper in this issue 
[ 37]. A generic answer might be that at least all objects which 
can be addressed by the network should have names as well so 
that high-level protocols can refer to them. For example, it 
might be reasonable for every host connection on the network 
to have an name and an address. There also may be objects 
internal to the network which also have addresses such as the 
statistics-gathering fake hosts in the ARPANET [38]. 

A related issue is whether objects should or can have multiple 
names, multiple addresses, and multiple routes by which they 
can be reached. The most general resolution of this issue is to 
permit multiple names, addresses, and routes to exist for the 
same object. An example taken from the multinetwork en¬ 
vironment may serve to illustrate this notion. Fig. 6 shows 
three networks which are interconnected by a number of gate¬ 
ways. Each gateway (or pair of gateway halves) has two inter¬ 
faces, one to each network to which it is attached. Plainly 
there is the possibility that several alternate routes passing 
through different gateways and networks could be used to 
carry packets from a source host in one net to a destination 
host in another net. This is just the analog of alternate routing 
within a single network. 

Furthermore, each gateway has two addresses, typically one 
for each attached network. This is just the analog of a host on 
one network attached to two or more packet switches for reli¬ 
ability. The term multihoming is often used to refer to mul¬ 
tiply attached hosts. 

Finally, it may be useful to permit a gateway to have more 
than one name, for example, one for each network to which it 
is attached.’ This might allow high-level protocols to force 
packets to be routed in certain ways for diagnostic or other 
reasons. Multiple naming also allows the use of nicknames for 
user convenience. Many of these same comments would apply 
to hosts attached to multiple networks. 

An interesting addressing and routing problem arises in mo¬ 
bile packet radio networks. Since hosts are free to move about, 
the network will need to dynamically change the routes used to 
reach each host. For robustness, it is also desirable that hosts 
be able to attach dynamically to different packet radios. Thus 
failure of a packet radio need not prevent hosts from accessing 
the network. This requires that host names and perhaps host 
addresses be decoupled from packet radio addresses. The net¬ 
work must be able to search for hosts or alternatively, hosts 
must “report-in” to the network so that their addresses can be 
associated with the attached packet radio to facilitate route 
selection based on host address. This is just a way of support¬ 
ing logical host addressing rather than using the more common 
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physical host addressing in which a host's address is an exten¬ 
sion of the packet-switch address. 

A crucial issue in network interconnection is the extent to 
which it should or must impact addressing procedures which 
are idiosyncratic to a particular network. It is advantageous 
not to require the subscribers on each network to have detailed 
knowledge of the network address structure of all intercon¬ 
nected networks. One possibility is to standardize an internet¬ 
work address structure which can be mapped into local net¬ 
work addresses as needed, either by subscribers, by gateways 
or by both. Subscribers would know howto map internetwork 
service names into addresses of the form NETWORK/SERVER. 
Subscribers need not know the fine structure of the SERVER 
field. Gateways would route packets on the basis of the NET¬ 
WORK part of the address until reaching a gateway attached 
to the'network identified by NETWORK- At this point, the 
gateway might interpret the SERVER part of the address, as 
necessary, to cause the packet to be delivered to the desired 
host. 

The addressing strategy presently under consideration by 
CCITT (X.121, [30]) is based on the telephone network. Up 
to 14 digits can be used in an address. The first 4 digits are a 
“destination network identification code” or DN1C. Some 
countries are allocated more than one DN1C (the United States 
has 200). The remaining ten digits may be used to implement 
a hierarchical addressing structure, much like the one used in 
the existing telephone network. 

Since the CCITT agreements are for international operation, 
it might be fair to assume that the United States will not need 
more than 200 public network identifiers. However, this 
scheme does not take into account the need for addressing 
private networks. The private networks, under this addressing 
procedure will most likely appear to be a collection of one or 
more terminals or host computers on one or more public net¬ 
works. It is too early to tell how much this asymmetry in ad¬ 
dressing between public and private networks will affect private 
multinetwork protocols. 

A related problem which is not unique to network intercon¬ 
nection has to do with addressing (really multiplexing and de¬ 
multiplexing) at higher protocol levels. The public carriers 
tend to offer services for terminal as well as host access to net¬ 
work facilities. This typically means that addresses must be 
assigned to terminals. The issue is whether the terminal address 
should be associated with or independent of the protocols 
used to support terminal-to-host communication. 

The present numbering scheme would not distinguish be¬ 
tween a host address and a terminal address. A host might 
have many addresses, each corresponding to a process waiting 
to service calling terminals. 

There has been discussion within CCITT concerning “subad¬ 
dressing" through the use of a user data field carried in virtual 
call “setup” packets. This notion would support the concept 
of a single host address with terminal or process level demulti¬ 
plexing achieved through the use of the user data field sub¬ 
addressing. 

It seems reasonable to predict that, as terminals increase in 
complexity and capability, it will eventually be attractive to 
support multiple concurrent associations between the terminal 
and several remote service facilities. Applications requiring 
this capability will need terminal multiplexing conventions 
beyond those currently provided for in the CCITT recommen¬ 
dations. 


197 | 

To simplify implementations of internet protocol softw ar 
it is essential to place bounds on the maximum size of >h 
NETWORK/SERVER address. Otherwise, subscribers mjj 
have to construct name-to-address mapping tables with arb>. 
trarily large and complex entries. 

Even if all these issues are resolved, there is still a question ot 
“source routing” in which a subscriber defines the route to t* 
taken by a particular packet or virtual circuit. Depending oc 
the range of internetwork services available, a subscriber maj 
want to control packet routes. It is not yet clear how such» 
capability will interact with access control conventions bu- 
this may be a desirable capability if gateways are not able to 
automatically select routes which match user service require¬ 
ments. 


D. Flow and Congestion Control 

For purposes of discussion, we distinguish between'flow a n e 
congestion control. Flow control is a procedure through which 
a pair of communicators regulate traffic flowing from source 
to destination (each direction possibly being dealt with sepi 
rately). Congestion control is a procedure whereby distributee 
network resources, such as channel bandwidth, buffer capaat) 
CPU capacity, and the like are protected from oversubscrip 
tion by all sources of network traffic. In general, the succeu 
ful operation of flow-control procedures for every pair of net 
work communicants does not guarantee that the netwuu 
resources will remain uncongested. 

In a single network, the control of flow and congestion u i 
complex and not well understood problem. In a multinct\M>:i 
environment it is even more complex, owing to the possiN* 
variations in flow and congestion control policies found -. 
each constituent network. For example, some networks nu< 
rigidly control the input of packets into the network and c< 
plicitly rule out dropping packets as a means of congest*' 1 
control. At the other extreme, some networks may dre; 
packets as the sole means of congestion control. 

At this stage of development, very little is known about 
behavior of congestion in multiply interconnected network 
It is clear that some mechanisms will be required which perr. 
gateways and networks to assert control over traffic in flu' ••> 
pecially when a gateway connects networks of widely varytrj 
capacity. This problem is likely to be most visible at u.iu-wj ' 1 
joining high speed local networks to long-haul public nc.> 
The peak rates of the local nets might exceed that of the h’--* 
haul nets by factors of 30-100 or more. Generic proa'dc-’’ 
are needed for gateway/network and gateway/gatewas t* • 
and congestion control. Such problems also show up in sint '“ 
networks, but are amplified in the multinetwork case. 


E. Accounting 

Accounting for internetwork traffic is an important PJ^ 
lem. The public networks need mechanisms for revenue 
ing and subscribers need simple procedures for verify in f 
accuracy of network-provided accountings. 

The public packet-switching networks appear to be c° n ' ^ 
ing on procedures which account for subscriber use ^ 
basis of the number of virtual circuits created during 
counting period and the number of packets sent onea ^ 

circuit. Indeed, it has been argued that accounting ^ 

basis of virtual circuits at gateways requires less overne ^ ^ 
accounting on a pure datagram basis [32], Scenarios 
cited which support the opposite conclusion. 
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Suppose there is a choice between setting up virtual circuits 

fof * aCh H thT -‘t" T d S£ndi118 3 datagram f or each transac- 
„ 0 „, and that virtual circuit accounting includes information 

° n IT If dif ClrCUlt S£tUP (3S in the Present telephone net- 

‘■l agLms sent m be a t CC0Untmg SimP ' y accumulat « the number 
■>' datagrams sent between particular sources and destinations 

.dhout regard to the time at which they are sent then the 
’mount of ®ocounting information which is collected for the 
Jitagrani case will be substantially less than for the virtual 
.ncui! ^se. In the limit (i.e., one packet per transaction) the 
nrtual circuit accounting information is proportional to 2 Af 
•here V is the number of transactions, while for the datagram 
.use it is proportional to log N (base 2). This is simply because 
:ht datagram case only sums counts for traffic between source/ 
iutination pairs while the virtual circuit accounting would 
Jentify start/stop times for each virtual circuit 
Alternatively, if the bulk of the traffic invokes a large num- 
of packets per transaction, then the two accountfng„ ” 
udures would accumulate more nearly the same information 
„nce c«ch would predominantly involve accounting for packet 
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between this strategy and the “common subnetwork” strategy, 
it is necessary to have some understanding of the X.25 packet 
network interface. X.25 provides a virtual circuit interface for 
the setup, use, and termination of virtual circuits between 
subscribers of the networks. X.25 provides for flow control of 
packets per virtual circuit flowing into or out of the network. 
Subscribers may set up switched virtual circuits by sending 
“call request” packets into the network and receiving “call 
confirmation” packets in return. The standard also provides 
for permanent virtual circuits. 

The public networks plan to employ X.25 interfaces; it can 
therefore be assumed that source and destination hosts in dif¬ 
ferent networks will essentially want to exchange “call request” 
and “call accepted” packets through the mediation of one or 
more gateways. This strategy could result in a series of virtual 
■circuits chaining source host to gateway, gateway to gateway, 
and gateway to destination host; alternately an end-to-end 
virtual circuit could be set up from source host to destination 
host, with the gateways acting as relays without any special 
knowledge of the virtual circuits passing across the network 
boundary. 

The principle difference between the X.25 interface and 
X.75 interface is that virtual circuit setup and clearing packets 
are passed transparently by the X.75 gateway to the next gate¬ 
way or destination. For reasons which are described below, it 
is necessary to maintain the sequence of packets belonging to 
a given X.25 virtual circuit as they pass through a gateway and 
enter the next network. Therefore, a virtual circuit is in fact 
created between the source host and intermediate gateway and 
between gateways. The X.75 gateway does not spontaneously 
generate any “call acceptance” packets in response to “call 
request” packets, but it does participate in the sequencing and 
flow control of packets on each virtual circuit passing through. 
Other differences between the X.25 and X.75 interface have to 
do with the nature of the internetwork accounting or routing 
information which might be exchanged over X.75 which would 
not be appropriate for a subscriber to exchange with the net¬ 
work over the X.25 interface. 

The design of the X.75 type of gateway depends in principle 
upon all networks’ use of the X.25 subscriber interface. Some 
networks, like the ETHERNET, cannot implement it without 
extensive modification, because there are no packet switches 
in the network to support the required packet reordering at 
the destination. The alternative is to insist that all internet 
applications rely on a sequenced data protocol built into the 
hosts or front-ends. For some services, such as packet speech, 
the potential overhead of resequencing packets before delivery 
to the destination may prevent the service from being viable. 
This problem could be amplified if packets are constrained to 
remain in sequence as they pass the X.75 boundary. 

Fig. 10(b) and (c) shows variants of the CCITT intercon¬ 
nection strategy. In Fig. 10(b), we see an example in which 
only X.25 is used both as a network access method and as a 
means of passing traffic across network boundaries. A single 
subscriber or a pair of subscribers to two nets could interface 
to their networks via X.25 and to each other by means of 
some agreed and possibly private protocol. 

Virtual circuits would be explicitly set up from source host 
to gateway, gateway to gateway, and gateway to destination 
host. The “internet” addresses of the source and destination 
hosts could be carried in the so-called “Call User Data Field” 
of an X.25 Call Request packet. This leaves the packet address 
field free to identify intermediate destinations (e.g., gateways), 
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but preserves an ultimate internetwork source/destination 
dress which the gateway can use to select the destination, 
which the next intermediate virtual circuit is to be set up 

An alternative to this is shown in Fig. 10(c) in which th 
subnets A and B use nonstandard virtual circuit interfaces but 
agree to build gateway software employing X.75 signaling p ri> 
cedures across the gateway interface. This solution is substm 
tially the same as that shown in Fig. 10(b), except there a 
now additional translation software in each gateway half t D 
make each virtual circuit network-access protocol compatible 
with X.75 procedures. 

There are some specific problems with the X.25/X.75 gate¬ 
way strategy, which do not necessarily apply to other virtue 
call gateways [63]. The basic X.25 interface provides for the 
sequence numbering of subscriber packets mod. 8 or, option 
. ally, mod. 128. Sincq.X.25 is. an interface specification, th» '■ 
numbering can only be relied upon to have local significance 
(i.e., host-to-packet switch). Some X.25 implementationsu* 
these host-assigned sequence numbers on an end-to-end bam 
Others generate internal, network-supplied numbers to alio* 
for repacking of subscriber packets into larger or smaller uniii 
for transport to the destination. If packet sequence numbers 
assigned by the source host were carried transparently to the 
destination without change, it might be possible to alio* 
packets to flow out-of-order across the X.75 boundary to r 
gateway and thence into the next network. If the packet sc 
quence numbers were still intact, they could be carried out-o' 
order to the next destination which might either be a gatesos 
or an X.25 host. In the latter case, the original packet-sequent 
numbers could be used to resequence the packets before de¬ 
livery. If the packets were being delivered to an intermodule 
gateway, they would not have to be sequenced there. Ho* 
ever, the X.25 interface specification does not underukc in 
carry the host-supplied sequence numbers to the destination 
gateway or host in a transparent fashion, primarily so that the 
subnetwork can deal more freely with the physical packagir.j 
of the packet stream. For example, a source may suprb 
packets of length 128 bytes while a destination may profci t-’ 
receive packets no longer than 64 bytes. To allow for su- 1 
variations, the network must be free to renumber packets :• •’ 
delivery. These considerations have two consequences. 

1) X.25 packet sequence numbers cannot be relied on 
end-to-end signaling, though they could be so used if requm-* 
information is known about the intermediate transit networks 

2) Packets must be delivered in sequence when passing to 
from gateways and hosts on X.25 networks. 

The second conclusion may be modified slightly. H u »■ 
least essential that packets be delivered in relative sequent o* 
each virtual circuit. By maintaining independent sequen^ 
numbering on each virtual circuit, it is possible for hosts 
gateways to refuse traffic on one virtual circuit while acup 
traffic on another. There are two penalties for this. 
gateway must keep track of which virtual circuits are p 
through it. Second, dynamic alternate routing of packets 
longing to the same virtual circuit through alternate ga 
is not possible without resetting or clearing the virtual cd ^ 
This last point is simply the consequence of not de!in* n *^ 
end-to-end sequence numbering scheme, but instead rely 
sequencing of the packets of a virtual circuit on entry 
exit from each intermediate network. ^ 

Some networks implement X.25 level acknowle 8”^^ 
(i.e., level 3) that have an end-to-end significance, but 
make this purely a host-to-packet switch matter. As a 
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Fig. 14. Us® of X.25 for public/private network interconnection. 


quence, it is not possible to rely on X.25 packet acknowledg¬ 
ments to determine which, if any, packets were not delivered 
as a result of the resetting or clearing of a virtual circuit. Fur¬ 
thermore, even if a subnet were to offer an end-to-end ac¬ 
knowledgment between a source host and an X.7 5 gateway, this 
could not be assumed to guarantee that the acknowledged 
packet was delivered to the ultimate X.25 destination in another 
network. 

X.75 is an interface intended for use between public net¬ 
works. Thus, it is not likely to be used or even allowed as an 
interlace between public networks and private networks. For 
the case illustrated in Fig. 14, X.25 interfaces could be pro¬ 
vided between public and private networks (or other special 
interfaces) and X.75 interfaces between public networks. Con¬ 
sequently, gateways between public and private networks are 
likely to appear to be ordinary host computers in the view of 
the public networks. 

The use of X.25 for private/public network interfaces and 
X.75 for public/public network interfaces leads to the situa¬ 
tion shown in Fig. 14 in which an internetwork virtual circuit 
*>ould have to be made up of several concatenated parts such 
is virtual circuits I-2-3-4 (see also [52, Fig. 3.4]). Even if 
X.25 implementations uniformly permitted an end-to-end 
interpretation of packet sequence numbers and acknowledg¬ 
ments, there would still be separate virtual circuits required 
between the source or destination hosts and'the gateways into 
the public networks. However, the concatenation of virtual 
circuits does not yield a virtual circuit. For instance, a gate- 
*ay between the public and private net could acknowledge a 
Picket but fail to get it delivered, in which case the subscriber 
*iU have been misinformed as to the delivery of the packet, 
^tis situation forces the end subscribers of private networks to 
‘mplement end-to-end procedures on top of any concatenated 
virtual circuits provided by the public networks. 

VIII. Practical Network Connections and 
Experiments in Progress 

A number of networks have been connected successfully 
0Ver the last few years. Most of these connections have been 
made in an ad hoc manner, using one of the following tech- 
Jiques. 

*) One network is a star network with remote RJE and in¬ 
active stations. The other is a star or distributed network 


with clearly defined protocols. A device on the star network 
provides exactly the functions required by its own network on 
one side, and those of the other network on the other side. 

2) Formal gateways are provided between the two networks, 
and protocol mapping occurs in the gateway. 

3) A computer is a host on two networks. It is arranged 
that services are provided by accepting input from one net¬ 
work and putting it out on another, possibly after substantial 
processing. 

4) Formal gateways are provided between the two networks. 
Sufficient agreement is obtained that end-to-end protocols 
(even high level ones) are common in the two networks. In 
this case, less activity is required in the gateway. 

In the first method, a form of front-end computer is used. 
It has been adopted in the large airline and banking networks 
S1TA [13] and SWIFT [14]. In each case the standards for 
the networks have been defined rigidly. SWIFT has even certi¬ 
fied officially the devices of three manufacturers to provide 
interfaces to its network. The other side of the device is then 
programmed to meet the requirements of the star system being 
attached. In the two cases cited, only a simple message level 
of interface needed to be defined. 

Other examples of the same technique are the connection of 
the Rutherford Laboratory (RL) star system [53] and the 
Livermore CTRNET to ARPANET. In these examples, more 
serious protocol mapping was required. ARPANET has a well- 
defined set of HOST-IMP, HOST-HOST, Virtual Terminal, and 
File Transfer protocols. All these had to be mapped into the 
appropriate procedures for the other network. 

The second method has been applied only experimentally. 
The UCL interface between ARPANET and the UK Post Office 
Experimental Packet Switched Service (EPSS, [55]) and the 
National Physical Laboratory interface between EPSS and the 
European Informatics Network (EIN, [ 56]) are examples of 
this technique; a demonstration has even been made of EIN- 
EPSS-ARPANET with no extra problems encountered from 
the three networks being concatenated. Technically there is 
almost no difference between the first two methods. The sec¬ 
ond looks at first sight somewhat more general than the first, 
but almost the same problems have to be overcome. The diffi¬ 
culties come from the fundamental differences in the design 
choices made in the protocols of the different networks; these 
differences are in general difficult, and even sometimes impos¬ 
sible, to resolve completely. In the first method, they can 
sometimes be. resolved using a specific facility in the star-net¬ 
work; in the second, where two distributed networks are in¬ 
volved, this recourse may no longer be available. 

One example of the problem occurs in the connection of 
EPSS and ARPANET. ARPANET can forward any number 
of characters at a time, and often uses full duplex remote echo¬ 
ing. EPSS works in a half-duplex mode, forwarding only com¬ 
plete records. A special “Transmit Now” has to be input by 
the user, and interpreted by the gateway, to ensure that partial 
records are forwarded. Another example, from the same appli¬ 
cation, occurs in File Transfer. ARPANET assumes an inter¬ 
active process is live throughout the file transfer; all comple¬ 
tion codes are passed over this live channel. The RL network 
(and EPSS) assume that file transfer is a batch process; they 
return network completion codes at a later time, and may 
delay acting on the commands. With the ARPANET-RL link 
[53], the file transfer job had to be given a very high priority, 
so that the completion code usually arrived before a timeout 
occurred; because of the nature of the way the computer was 
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used for large real-time jobs, this did not always ensure that 
the job was run in a reasonable time. 

There are several examples of the third technique. A DEC 
PDP 10 machine used on the Stanford University SUMEX 
project is a host both on ARPANET and on TYMNET; several 
machines at Bolt, Beranek and Newman are both on ARPANET 
and TELENET. Because the TENEX operating system has 
good facilities for linking between programs, it would be pos¬ 
sible for interactive streams to come in one network and go 
out on another. File transfer problems would be simple in this 
configuration, because the hosts obey all the conventions, in 
any case, of each network. Of course, this mode of operation 
may require that files in transit between networks may have to 
be stored temporarily in their entirety in the host serving as 
the gateway between the networks. 

The fourth'technique is newer, and has many variations. As 
a Jesuit of agreement on the X.25, and partial agreement on 
the X.75, protocols, PTT networks are able to interconnect in 
a reasonably straightforward manner. The connections between 
DATAPAC and both TELENET and TYMNET have been done 
in this way. In each case, there has not been any agreement on 
higher level protocols, so the problems of host-host communi¬ 
cation across concatenated networks is not resolved by these 
linkups of the subnets. 

The ARPA-sponsored INTERNET project has tried to stan¬ 
dardize to a higher level. A host-host protocol has been defined 
(TCP, [25]), and is being implemented on a number of differ¬ 
ent networks including Packet Radio [20], [21], ETHERNET 
[18], LCSNET [64] and the SATNET [22], in addition to 
ARPANET. This protocol is defined for use across networks; 
thus each packet includes an “Internet Header” which is kept 
invariant as the packet crosses the different networks. One 
aspect of the INTERNET program is to develop gateways 
which can interpret this header appropriately. 

By late 1976, the ARPA project had connected together the 
Packet Radio Network, the ARPANET, and the Atlantic Packet 
Satellite Network using two gateways between the Packet Radio 
Network and the ARPANET and three gateways between the 
ARPANET and Packet Satellite Network. It is routinely pos¬ 
sible to access ARPANET computing resources via either of 
the other nets and to artificially route traffic through multiple 
nets to test the impact on performance. In one such test, a 
user in a mobile van in the San Francisco area accessed a DEC 
PDP-10 TENEX system at the University of Southern Califor¬ 
nia’s Information Sciences Institute over the following path: 

1) from van to the first gateway into ARPANET via the 
Packet Radio Network; 

2) across the ARPANET to a second gateway in London, 
using a satellite link internal to the ARPANET; 

3) across the Atlantic Satellite Network to a third gateway 
in Boston; 

4) across the ARPANET again to USC-ISI. 

The user and server were 400 geographical miles apart, but the 
communication path was 50000 miles long and passed through 
three gateways and four networks. Except for a slightly in¬ 
creased round-trip delay time, service was equivalent to a direct 
path through the ARPANET. Since the Packet Radio Network 
is potentially lossy, can duplicate packets, andean deliver pack¬ 
ets out of order, the end/end TCP protocol was used to exer¬ 
cise flow and error control on an end-to-end basis. The avail¬ 
ability of a common set of host-level protocols substantially 
aided the ease with which this test could be conducted. 


The ARPA project also has high-level standard protocols a! 
ready in existence to support file transfer and virtual terminals 
(the FTP and TELNET protocols [40]), and these are being 
retrofitted above the internet TCP protocol to provide a stan¬ 
dard high-level internetwork protocol hierarchy. 

IX. Regulatory Issues 

The regulatory issues in the interconnection of packet net- 
works takes a different form in North America than elsewhere 
It is hard in a paper of this type to more than touch on some 
of the problems involved. The discussion here is simplistic in 
the extreme, and no attempt is made to put the issues in the 
legalistic language they really require. 

In almost all countries the provision of long distance com¬ 
munication transmission, and switching is provided by a regu¬ 
lated carrier. In most countries outside North America, this 
carrier is a single national entity—called the “PTT”. In some 
countries (e.g., Italy) there are different carriers for different 
services—e.g., telegraph, telephone, intercity, international 
telephone, etc. In North America there are many carriers. 
Usually only one in each geographical area has a monopoly on 
public switched voice traffic. Also the so-called “Record Car¬ 
riers” have some sort of monopoly on “record traffic," which 
is message traffic. In a “Value Added Network” (VAN), the 
operators rent transmission equipment from the carriers, and 
then add their own switching equipment. These VAN’s arc 
themselves regulated in what they may do, what traffic they 
may carry, and what rates they may charge. Between North 
America and Europe, specific “International Record Carriers" 
(IRC) have monopoly rights on data and message transmission 
—in collaboration with the appropriate European PTT’s. The 
regulations take into account who owns the hosts and termi¬ 
nals, who owns the switches, who rents the transmission lines, 
what types of traffic is carried, what is the geographic extent 
of the network, and what is the technology of long distance 
transmission. 

In Fig. 15, a single network N is sketched. It consists of 
switches S and transmission lines L \ these together are called 
the data network, DN. It consists also of terminals T and 
hosts H; the exact difference between a terminal and a host is 
not very clear; we believe it is assumed that terminals mainl) 
enter and retrieve data without processing; while a host trans¬ 
forms the information by processing. This definition probably 
does not meet the picture of modern “intelligent terminals, 
but it is always hard for the regulations to keep up with the 
technology. If the total network is all localized in one site, so 
that no communication lines cross public rights of wav. 
then it can usually be considered from a regulatory viewpoint- 
as a single host in more complex network connections. The 
hosts and the terminals can be connected to the switches, an 
the switches to each other, either by leased lines, or by t 
Public Switched Telephone Network; the first type of conne^ 
tion is called a leased connection, the second switched. In 1 e 
subsequent discussion of this section, the term “host” will m 
elude localized networks. In general we will assume the con¬ 
nections between the switches are via leased lines; if that is 
the case, the regulations are much eased in general (though in 
some countries, like Brazil, no data transmission is permi 
at all via switched telephone lines). 

If all the hosts and switches are owned by one organiza i 
P, which also leases the lines, then P is said to own and ope ^ 
the network, and it is called a “Private Network.” There 
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Fig. 1 6. Schematic of two connected networks. 


Fig. 1 S. Schematic of one network. 


^-nal restrictions on such networks—though in West Ger- 
rfVi for example, higher tariffs are charged for the leased 
< if any terminals or hosts are connected via the PSTN. In 
z countries such a network may not be used for the trans- 
0 f messages between terminals belonging to organizations 
than P. 

the data network belongs to one organization, and the 
ci to others, the data network is a VAN. Stringent regula- 
3 apply to VAN’s, in most countries. With rare exceptions, 
nost European countries, VAN’s can be operated only by 
PTT’s. In the U.S., they can be operated by other organi¬ 
cs, but only if approved as regulated Value Added Car- 
i (VAC’s) by the Federal Communications Commission 
,-a'). One regulation imposed by the U.S. is that an organiza- 
ii operating as a VAC may not also operate a host for out¬ 
er sale of services. For this reason, the companies TYM- 
.'.tRE and ITT have had to spin off their VAC’s into separate 
.isJiaries, TYMNET and ITT Data Services. 

; the past, a few VAN’s have been permitted to operate 
^nationally for specific interest groups. Two such VAN’s 
.- S1TA [ 14], for the airlines, and SWIFT [14] for the bank- 
* rommunity. Here the regulations can be stringent. SWIFT 
a to pay specially high tariffs for its leased lines; its license 
tperate may be revoked when the PTT’s can offer a com- 
nble international service. 

usoon as two networks, owned by different organizations, 
r tatti-connected, there are regulatory difficulties. This situ- 
:i -3 is illustrated schematically in Fig. 16. Even if one net- 
"i is an internal one, so that it can be treated as a single 
l ' ,< - >ts connection to other network immediately changes the 
‘"-.•i s status. Thus in Fig. 16, the connection of DN I to DN2 
Mediately changes DN2 to a VAN. In Europe it has been 
t -'«d that such private networks may. riot connect directly 
;lctl other, but only through a PTT network. Thus the 
‘ ,s general configuration permitted by the European PTT’s 
titrated in Fig. 17. Moreover, the PTT’s have also agreed 
0| % the X.25 interface will be provided to customers, 
’■‘-gh that interface was defined for the configuration of Fig. 

‘therthan 17. The different PTT networks will themselves 
^ tct to each other by the different interface X.75 as illus- 
''d in Fig. 18 , This does not change, however, the inter- 
*en by the private networks. Further work is needed to 
suitability of X.25 in this role. 

U.S., the regulations are not quite so stringent. Con- 
^ ns such as Fig. 15 are permitted even where one host 
> to a different organization than the network operator 
'•° v ided such connection is only limited and for the pur-' 
^ “fusing the facilities of that network. This type ofre- 
. f 0n 's really necessary, because of the difficulty of dis- 
I ^“i'ing between a “host” and a “terminal”. In practice, in 



Fig. 17. Schematic of PTT model. 



Fig. 18. Multiple PTT network interconnection. 


most countries, the line is drawn between leased line and PSTN 
connections. The former are usually not permitted without 
change of status of the network; the latter seem to downgrade 
the connection to that of a terminal. 

The discussion above has treated the types of connections 
which can be made. In addition, the PTT’s, and the FCC in 
the U.S., usually regulate the purposes for which the network 
can be used. In particular, there is a ban on such networks 
being used for message or voice transmission between organi¬ 
zations. How such measures are to be policed, gets us into 
another regulatory problem. For example the UK PO [57] 
has claimed a right to inspect the contents of any data message 
sent across lines leased from it; this right would be at variance 
with the privacy laws being enacted in many countries [58], 
[591. This subject is a large one in its own right, and it is 
clearly beyond the scope of this paper. 

Two other service problems will arise in international con¬ 
nections. First the impact and form of the privacy and trans¬ 
national data flow regulations in different countries are differ¬ 
ent. Thus in the interconnection of international networks, a 
particular set of problems may arise, even when the appropri¬ 
ate regulations are obeyed in each network separately. Thus 
both Network 1 in country A and Network 2 in country B 
may obey their own national regulations. However when the 
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-ting computer networks. Moreover, no single set of tech- 
^ucs will fit all applications. 

services which will normally have to be supported are 
^inal access, bulk transfer, remote job entry, and transac- 
, Q processing. The quality and facilities of the services re- 
^red will be very dependent on the applications. 

^The connections between networks can be made at the level 
,packet switches or of hosts, and can be on a datagram 
\ virtual call basis. Connection at the packet-switch level 
-quires broadly similar network access procedures, or com- 
x protocol transformation at the gateways between the 
jfiworks. If the network protocols are different, intercon- 
^•tion can be most easily achieved if done at the host level. 
-w e higher levels of service can be mapped at service centers, 
liich need not be colocated with the gateways—but very 
••ferent philosophies of network services can be very difficult 

- map. Alternatively, subscribers can implement common 
^er level protocols if these can be agreed upon. 

fhc principal problems in connecting networks are much the 
tat as those in the design of the individual networks of het- 
-.-geneous systems—but the lack of a single controlling au- 
^jrity can make the multinet design problem more difficult 

- solve. It is essential to resolve the usual problems of flow 
-mrol, congestion control, routing, addressing, fault recovery, 
Nubility, protocol standards, and economy. The public car- 
acre have attempted to resolve many of these problems; par- 
•i-jlarly in the areas of flexibility, addressing, and economy 

feel their solutions are not yet adequate. At the higher 
ncls of protocol, much more standardization is required be- 
-.re we have really satisfactory long term solutions. 

The advent of international computer networks, private net- 
orks which must communicate with other private networks 
nen if via public ones), and the new applications of computer 
networks, raise regulatory and legal issues which are far from 
-wlution. 


Many technical solutions to the problems of the connection 
••• networks are discussed in this paper. Their applicability in 
tv of the different technical, economic, and policy con- 
snints imposed in different countries must still be assessed. 
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